May I ask that you import the module directly and avoid import * in general? This pulls everythin into the top-level namespace makes it harder to see where things come from and to avoid name clashes. I realize that this idiom is used throughout optimism, but I've been trying to remove them bit by bit.

You shouldn't need this import. It's a legacy thing I'm trying to remove. If it doesn't work without it, show me the error and I'll fix it.

I happen to like import * from JaxConfig. For me, its intent was to avoid having to constantly duplicate lots of lines like: from jax import grad, import blah, ... which I found to be annoying in every file. It's an example where the DRY (dont repeat yourself) principal is in conflict with other principals. For me, I like DRY here, but I know there is a trade off. I understand that it pull in extra things, but that is essentially the point! Without it, the tops of files are more verbose and it takes longer to get to the actual work of the file without such things. If JaxConfig pull in things that may be duplicated or we don't want, we should delete them from JaxConfig.

Plus, the way I think about it at least, I don't want to type jax.grad, because that is essentially hard-coding the implemenation to jax (which we are hard coded to anyway, but whatever). Its like in c++, where you can say using MatrixClass = Eigen::Matrix, but, potentially, if one is very careful, it is possible to switch out the matrix by just changing MatrixClass = Armadillo::Matrix. So, I don't think of it as polluting the namespace, I think of it as concretizing the specific grad our library is using.

I understand what you mean, but there are better ways of doing that. The wildcard import is discouraged pretty much universally because it makes it so hard to understand where things are coming from, and names can collide and unintentionally overwrite the one you want. It's essentially like a GOTO - you'd have to follow all the import * instances to see which grad you're ultimately getting. Even the Python project itself doesn't allow it in their style any more. If you want to use the concretization/substitution idea, there are ways to do it by importing things in the __init__.py file for the project, which is similar, but forces you to be explicit (like your MatrixClass = Armadillo::Matrix example).

OK, can we basically put things like grad = jax.grad, etc. in init then? Basically things which are essentially always used and in the way we generally want to use them, so we can establish a standard way of doing it. That was the intent of the .Config file. In C++, the equivalent is basically #include "types.hpp", where types are put into the same namespace as the project on purpose. That is essentially the same thing I want to do in python. The issues is that putting it in init puts in in EVERY file, where as "from optimism.types import *" is more selective. So I don't really appreciate what the issue with that is. We are not doing "from jax import *", we are including a types header.

I think we should discuss this offline. Ryan, you can leave things as they are until we come to an agreement.

Ok, go ahead and leave the wildcard import. We'll make a sweeping change in the future to get rid of them. Try to leave out the JaxConfig import in the future.

This function appears to be copied and pasted from FunctionSpace - why not use that directly?

Good catch, fixed it.

The permissions on this file are wrong: it's currently marked as executable.

For consistency, can you import numpy as onp here? We try to be consistent about calling the jax numpy np and the original numpy as onp. It makes it easier to understand a file at a glance.

Thanks, those warnings were annoying.

Ok, go ahead and leave the wildcard import. We'll make a sweeping change in the future to get rid of them. Try to leave out the JaxConfig import in the future.